オンデマンド無線サービスのための適応ストリーミング

专利摘要:
適応メディア配信システムは、拡張メモリソリューションの増大した利用可能性の利点を採用して、ハンドヘルド通信デバイス上の利用可能な記憶装置を選択的に利用することによって、スループットが制限された無線ネットワークを通して、オンデマンドユーザー経験を提供する。適応可能なユーザーインターフェース（UI）ウィジェット（例えば、トリッグ）の創造は、メディアコンテンツの配信のために準実時間メカニズムとして役立ち、無線待ち時間およびストリーミング相互運用性の問題を克服する。さらにまた、制限された記憶ストレージを有するハンドヘルド通信デバイスに対して、適応メディア配信システムは、さらに、携帯マルチメディアサービスに関連付けられた必須の比較的な長い待ち時間を伴うにも拘わらず、旧来のデバイスがストリーミングを介してオンデマンドサービスを受信できるようにする。1
公开号:JP2011508569A
申请号:JP2010540827
申请日:2008-12-22
公开日:2011-03-10
发明作者:ハンター、ケビン・イー．；マンディアム、ジリッドハー・ディー．
申请人:クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ；
IPC主号:H04W4-06

专利说明:

[0001] 本態様は、一般に、ソフトウェアアプリケーションの可変処理に関する。さらに詳細には、本態様は、スループットが制限された携帯通信チャネルを通して、改善されたマルチメディア配信を提供することに関する。]
背景技術

[0002] 携帯アクセステクノロジーを使用するストリーミングサービスは遍在に達しつつある。そのようなサービスの普及は、エンドユーザーが、少なくとも近いうちに、ハンドヘルド環境の移動性を楽しむために制限された形式の映像コンテンツ（limited forms of video content）への適応を望んでいることを示している。利用可能なスループットとアクセスコストによって課せられた制限は、低い解像度のストリーミングコンテンツおよび／または少なくともコンテンツの一部をバッファするための長い待ち時間を含む。一方、高帯域幅アクセス（例えば、インターネットブロードバンド、Wi-Fiなど）を有する他の通信デバイスは、マルチメディアコンテンツにアクセスするために益々使用されており、映像オンデマンド経験に、より良い解像度と短縮された待ち時間を提供している。]
[0003] 以下に、開示されるバージョンの幾つかの態様の基本的な理解を提供するために、簡潔な概要が示される。この概要は広範囲の概観ではなく、キーまたは不可欠なエレメントを識別せず、またはそのようなバージョンの範囲を描写しないことを意図する。この目的は、後ほど示されるさらに詳細な記述の前置きとして、記述されたバージョンの幾つかのコンセプトを簡潔な形態で示すことである。]
[0004] 適応メディア配信システムおよび方法は、モバイルデバイス上の記憶装置にネットワークから個別メディアファイルを送信することによって、縮小された帯域幅の通信チャネルを介したオンデマンドメディア配信を提供する。それにより、ユーザーは、メディアのストリーミングバージョンにアクセスすることと比較すると、短縮された無線待ち時間でメディアにアクセスできる。利用可能な記憶領域が著しく制限されるモバイルデバイスのある態様において、システムと方法は、ストリーミングメディアコンテンツに復帰（reversion）することを可能にする。]
[0005] ある態様において、制限されたスループットのネットワークを通してメディアコンテンツを受信する方法は、閾値以下の利用可能なローカルデータ記憶容量に応答して、ポータブル通信デバイス上でメディアコンテンツ選択のストリーミングバージョンにアクセスし、再生（play）する。方法は、さらに、閾値を超える利用可能なローカルデータ記憶容量に応答して、利用可能なローカルデータ記憶装置に、メディアコンテンツ選択の個別にフォーマットされたバージョンを記憶する。]
[0006] 別の態様において、制限スループットネットワークを通してメディアコンテンツを配信する方法は、個別のメディアコンテンツバージョンを記憶するための通信デバイスの容量を決定することに応答して、制限スループットネットワークを通して個別メディアコンテンツバージョンを送信する。]
[0007] さらなる態様において、制限スループットネットワークを通してメディアコンテンツを受信するように構成された少なくとも1つのプロセッサは、利用可能なローカルデータ記憶容量を検出する第1のモジュールと、メディアコンテンツ選択に対するユーザー嗜好（user preference）を決定する第2のモジュールと、閾値以下の利用可能なローカルデータ記憶容量に応答して、ポータブル通信デバイス上でメディアコンテンツ選択のストリーミングバージョンにアクセスして再生する第3のモジュールと、閾値を超える利用可能なローカルデータ記憶容量に応答して、利用可能ローカルデータ記憶装置においてメディアコンテンツ選択の個別にフォーマットされたバージョンを記憶する第4のモジュールを有する。]
[0008] さらなる態様において、コンピュータプログラム製品は、利用可能なローカルデータ記憶容量をコンピュータに検出させる少なくとも1つの命令と、メディアコンテンツ選択に対するユーザー嗜好をコンピュータに決定させる少なくとも1つの命令と、閾値以下の利用可能なローカルデータ記憶容量に応答して、ポータブル通信デバイス上でメディアコンテンツ選択のストリーミングバージョンをコンピュータにアクセスさせ、再生させる少なくとも1つの命令と、閾値を超える利用可能なローカルデータ記憶容量に応答して、利用可能ローカルデータ記憶装置でメディアコンテンツ選択の個別にフォーマットされたバージョンをコンピュータに記憶させる少なくとも1つの命令を備えるコンピュータ読み取り可能メディアを有する。]
[0009] さらに別の態様において、装置は、利用可能なローカルデータ記憶容量を検出する手段、メディアコンテンツ選択に対するユーザー嗜好を決定する手段、閾値以下の利用可能なローカルデータ記憶容量に応答して、ポータブル通信デバイス上でメディアコンテンツ選択のストリーミングバージョンにアクセスしてプレイする手段、および、閾値を超える利用可能なローカルデータ記憶装置の量に応答して、利用可能ローカルデータ記憶装置にメディアコンテンツ選択の個別にフォーマットされたバージョンを記憶する手段を提供する。]
[0010] さらに追加の態様において、制限スループットネットワークを通してメディアコンテンツを受信する装置は、メディアプレーヤで再生するために、リムーバブル記憶装置上の無線通信インターフェースから受信される個別メディアコンテンツを記憶するためのリムーバブル記憶装置の存在に応答する適応メディアアプリケーションを有する。]
[0011] さらなる態様において、少なくとも1つのプロセッサは、メディアコンテンツの選択を決定する第1のモジュールを有することによって、制限スループットネットワークを通してメディアコンテンツを配信するように構成される。第2のモジュールは、アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造で構成される選択の個別メディアコンテンツバージョンを獲得する。第3のモジュールは、個別メディアコンテンツバージョンを記憶するための通信デバイスの容量を決定することに応答して、制限スループットネットワークを通して個別メディアコンテンツバージョンを送信する。]
[0012] さらなる態様において、コンピュータ読み取り可能メディアのコンピュータプログラム製品は、メディアコンテンツの選択をコンピュータに決定させる少なくとも1つの命令と、アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造で構成される選択の個別メディアコンテンツバージョンをコンピュータに獲得させる少なくとも1つの命令と、個別メディアコンテンツバージョンを記憶するために通信デバイスの容量を決定することに応答して、制限スループットネットワークを通して個別メディアコンテンツバージョンをコンピュータに送信させる少なくとも1つの命令を有する。]
[0013] 別の態様において、装置は、メディアコンテンツの選択を決定し、アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造で構成される選択の個別メディアコンテンツバージョンを獲得し、個別メディアコンテンツバージョンを記憶するための通信デバイスの容量を決定することに応答して、制限スループットネットワークを通して個別メディアコンテンツバージョンを送信する手段を提供する。]
[0014] さらなる態様において、装置は、制限スループットネットワークに接続された通信インターフェースを有する。メディアディストリビュータは、メディアコンテンツの選択を決定するために、メディアコンテンツにリンクされる。データ記憶装置は、アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造で構成される選択の個別メディアコンテンツバージョンを含む。スケジューリングディスパッチャ（scheduling dispatcher）は、決定された制約を条件として、通信デバイスへの通信インターフェースを介して個別メディアコンテンツバージョンを配信する。]
[0015] 前述および関係する目的の達成ために、1つ以上のバージョンは、以下に十分に記述される特徴を備え、請求項において詳しく示される。以下の記述および添付図は、幾つかの実例となる態様を詳細に示し、バージョンの原理が用いられる少数ではあるが様々な方法を示す。別の利点および新しい特徴は、図に関連して考慮した場合、下記の詳細な記述から明白になるであろう。そして、開示されるバージョンは、全てのそのような態様およびそれらと同等のものを含むことを意図する。]
図面の簡単な説明

[0016] 図1は、ある態様に従って、無線ネットワーク上で記憶可能モバイルデバイスに準実時間メディア配信を行うための通信システムのブロック図である。
図2は、別の態様に従って、フレームが送られる初期無線エラー率ｐ対高速ダウンリンクパケットアクセス（HSDPA）のためのファイル転送ラグDのプロットである。
図3は、さらに別の態様に従って、映像ストリーミングサービスの待ち時間の問題を取り扱う方法において、第3世代無線ネットワーク上で、オンデマンドで準実時間（near real-time）メディア送信するための図1の通信システムの例示的な携帯通信システムのブロック図である。
図4は、さらに別の態様に従って、メディアコンテンツを通信するためのユーザーインターフェースウィジェット、トリッグ、およびアクタを利用するプログラム環境の図である。
図5は、さらに別の態様に従って、制限スループット通信チャネル上でメディアコンテンツを配信する方法のフロー図である。
図6は、また別の態様に従って、制限スループット通信チャネル上でメディアコンテンツを受信する方法のフロー図である。]
発明の詳細な説明

[0017] 様々な態様が図に関係して記述される。以下の記述において、説明の目的のために、数々の特定の詳細は、1つ以上の態様の完全な理解を提供するために示される。しかし、様々な態様は、これらの特定の詳細無しに実施されうることは明白である。別の例において、周知の構造およびデバイスは、これらのバージョンを簡潔に記述するために、ブロック図の形で示される。]
[0018] 以下の記述において、「例示的」という用語は、「実例、事例、例証として提供される」を意味するために本明細書で使用される。「例示的」として本明細書に記述されている任意の態様または設計は、必ずしも他の態様または設計より有利または優先されるとして解釈されるわけではない。むしろ、「例示的」という用語の使用は、具体的な形態におけるコンセプトを示すことを意図する。本明細書に使用されるように、「または」という用語は、排他的な「または」よりはむしろ包括的な「または」を意味するために示される。すなわち、そうではないことが明示されていない限り、またはコンテキストからそうではないことが明らかでない限り、表現「XはAまたはBを用いる」は、任意の普通の包括的な入替えを意味するために示される。つまり、この例において、それは「XはAを用いる、XはBを用いる、または、XはAとBとの両方を用いる」であり、従って「XはAまたはBを用いる」は、前記例のいずれをも満たされる。加えて、この明細書に使用される冠詞「a」と「an」および添付された請求項は、一般的に、そうではないと明確に示されていない限り、または単数形に向けられていることがコンテキストから明らかでない限り、「1つ以上の」を意味すると解釈される。]
[0019] 提供される装置と方法は、特に無線環境における使用に適切であるが、通信ネットワーク、インターネットなどの公衆ネットワーク、仮想施設ネットワーク（VPN）などの私設ネットワーク、ローカルエリアネットワーク、広域ネットワーク、長距離ネットワーク、または任意の別のタイプのデータ通信ネットワークを含むがそれに限定されない任意のタイプのネットワーク環境において適応しうる。]
[0020] 図1において、通信システム10は、プロバイダソース（例えば、データベース）16に記憶されたメディアコンテンツ14（例えば、映像、音声など）にアクセスするメディアコンテンツディストリビュータ12を含む。通信システム10は、さらに、実例となるバージョンにおいて、無線ネットワーク18を備える通信チャネルを通して、記憶可能モバイルデバイス20および記憶制限モバイルデバイス22として描写される受信側デバイスにメディアコンテンツ14を配信する。]
[0021] 無線ネットワーク18は、通信サービスの映像オンデマンドタイプの準実時間メディア配信に十分な、制限されたデータスループットを提供する。そのために、メディアコンテンツディストリビュータ12により利用されるメディア配信アプリケーション24はメディアコンテンツ14を受信する。メディアコンテンツ14は、次に、ストリーミングコンテンツフィルタ26により映像ストリーミングフォーマットに変換され、その後、ストリーミングユーティリティ28においてバッファまたは記憶される。スケジューリングディスパッチャ29は、メディアコンテンツを送信する要求に応答する。通信インターフェース30は、次に、無線ネットワーク18を通して要求中の記憶制限モバイルデバイス22に映像ストリーミング信号を送信する。]
[0022] 制限モバイルデバイス22の通信インターフェース32は、必要に応じて制御信号を交換し、ストリーミングコンテンツを受信する。制限モバイルデバイス22の内蔵データ記憶装置は、内蔵記憶装置36の利用不可能記憶部38（例えば、空の拡張ドック、大量の記憶コードまたはデータ、制限記憶構造など）と比べると比較的小さな利用可能記憶部34で描写される通り、制約されている。従って、メディアアプリケーション40は、人間が理解可能なメディアプレゼンテーション46（例えば、見る、聴く、触れることができる）としてレンダリングまたは再生するために、データバス42を通して出力デバイス44にストリーミング映像信号を導く。]
[0023] 幾つかの例において、拡張された記憶装置が、同一のモバイルデバイスで利用可能になる（例えば、記憶コンテンツの削除、メモリ記憶装置の挿入など）、または、比較的より大きい記憶装置のリソースが相手先ブランド製造会社（OEM）によって提供される。記憶可能モバイルデバイス20は、記憶装置50の利用不可能記憶部52と比べると比較的大きい利用可能記憶部48を有する。従って、準実時間メディアオンデマンドシステム54のダウンストリーム部はスループットが制限された無線ネットワーク18の制約を緩和し、高帯域幅ではあるが短距離のネットワーク（例えば、インターネットWi-Fi）に特有の映像オンデマンド経験の、より多くの経験を提供する。そのために、メディアアプリケーション56は、常に、または選択的に、記憶デバイス50に記憶される個別メディアファイル62を通信インターフェース58および内蔵データバス60を介してメディアコンテンツディストリビュータ12から要求して受信し、その後、出力デバイス66上で、人間が理解可能なメディアプレゼンテーション64（例えば、見る、聴く、触れることができる）としてレンダリングまたは再生する。メディアコンテンツディストリビュータ12は準実時間メディアオンデマンドシステム54のアップストリーム部を備えそれは、個別ファイルフォーマットに変換するためにメディアコンテンツ14を個別コンテンツフィルタ68に向かわせるメディア配信アプリケーション24として描写され、無線ネットワーク18を通した通信インターフェース30による後の配信のために、ファイルユーティリティ70により記憶またはバッファされる。スケジューリングディスパッチャ29は、個別ファイルフォーマットを最適に配信するための制約に敏感に応答する。このように、準実時間メディアオンデマンドシステム54は、遠隔デバイス上で再生されるストリーミングコンテンツを要求する際の待ち時間を有利に避けるバックグラウンドダウンロードを実行することにより、ストリーミングを避ける。そのようなダウンロードは、また、コストを削減するため、および／または、別目的で送信スループットを使える状態にするために、低需要期間に有利に発生する。]
[0024] 例示的なオペレーティング環境として、高速パケットアクセス（HSPA）、および、1xEV-DO（国際電気通信連合（ITU：International Telecommunication Union）により定義される1x進化データ専用、後の高速データ通信の最適化、a.k.a. IS-856）などの第3世代（3G）無線システム上のメディアストリーミングサービスは、ブロードバンド接続上の類似サービスにおいて見受けられるスループット制限にあたる。一例として、サービスの質（QoS）は、長い無線データセッションでは一貫性はない。加えて、ストリームの平均遅延は無線リンクによって影響をうける。結果として、効果的なプレイバックを確実にするために、受信機バッファリング（receiver buffering）は増える必要があり、そうしなければユーザー経験が損害をうける。例えば、データが共有物理チャネル（即ち、高速ダウンリンク共有チャネル（HS-DSCH））を介して個々のユーザーに送信される万国移動通信システム（UMTS）リリース5（すなわち、高速ダウンリンクパケットアクセス（HSDPA：High Speed Downlink Shared Channel））が考えられる。このデータ転送の一部として、高速自動再送要求（ARQ：automatic repeat request）方式（a.k.a.ハイブリッドARQ）が、データの信頼性を確実にするために使用される。]
[0025] パフォーマンスはハイブリッドARQのコンテキストにおけるHSDPAのために予測可能で、ハンドヘルドデバイスに映像ファイルを送信するために必要な期待時間量に関する遅延境界線を決定することが理論的に示されている。この遅延は、物理リンク上のエラーに影響される。エラーの2つの主なソースは、誤って受信されるパケット、およびARQ応答（ARQ acknowledgement）の誤解による損失パケットである。さらに、エラー検知後の再送信はすぐに到着しない。結果として、「Ｎ位相停止および待機ハイブリッドARQ（N-phase stop-and-wait hybrid ARQ）」メカニズムが使用される。この方式において、幾つかのARQ例が開始され、応答所要時間（acknowledgement turnaround time）の間、データ送信におけるギャップは発生しない。例えば、物理層フレーム持続時間がTとして明記される場合、フレームエラーの検出により再送信が起こるまでにNT時間を要する。HSDPAにおいて、Tは約2ミリセカンドであり、Nは約4ミリセカンドである。]
[0026] HSDPAのために定義されるハイブリッドARQ方式において、M回の送信の後、送信された物理層フレームは回復不可能と見なされる。結果として、無線リンクプロトコル（RLP）またはトランスポート層プロトコル（TCP）などの高層プロトコルは、データを回復するように作用する。フレームが送信される初期無線エラー率がpで示されるある例において、それに続く各再送信は、ファクターCだけの近似縮小エラーという結果になる。]
[0027] ハイブリッドARQの効果は、応答中のエラーによって制限される。さらに詳細には、エラーにおいて受信される否定応答（NAK）は、関連データフレームが正確に受信されたと誤って示すHSDPA送信機という結果になる。この場合は、RLPまたはTCPがエラー回復のために使用される。応答エラーの確率がfであると仮定すると、ハイブリッドARQによるフレームごとの平均遅延は下記の通り近似される：]
[0028] ここで、AddMは下記の通り定義される：]
[0029] ファイルサイズがFと定義され、1秒ごとのビットにおける送信率がRの場合、ファイル全体を送信するために必要な物理層フレームの最小数は：]
[0030] である。結果として、このファイルを送信するための全般的なラグはL=DKと定義される。]
[0031] 例として、順方向エラー修正コード速度が3／4で、物理層データ速度が毎秒708キロビット（kbps）の16直交振幅変調（QAM：Quadrature Amplitude Modulation）での単一コードHSDPA送信を仮定する。この場合C=0.1である。M=4で、fが異なる値をとると仮定すると、異なる値をとるpに関する遅延は図2に示される（128kbpsで符号化された、約4分の長さの映像ファイルを仮定）。総合的な遅延は、典型的な値p（すなわち、0.1から0.3）については1分に近づく。さらに、HSDPAまたは1X-EV-DOのいずれかにおいて見受けられる最速データ速度を提供する16QAMは、限定されたカバレッジ範囲を有し、エンドユーザーにより見られる平均的スループットの典型ではない。また、付加的プロトコルオーバーヘッド（例えば、RLP、TCP/IPおよびストリーミングプロトコルヘッダーなど）、無線リンクプロトコル実装による返答遅延、およびTCP関連遅延（例えば、スタートアップ、再送信遅延）などの幾つかの別の制限要因は含まれていないので、図2で提供される遅延は下限であることに注意されたい。]
[0032] この遅延効果は今日の3Gネットワークにおいて容易に観察でき、多くのユーザーは、この効果を説明するために生じる幾つかの犠牲に満足している（例えば、短縮された映像持続時間、より低品質の符号化など）。しかし、このようなラグはオンデマンドサービスが不可能となる地点に近づき始めている。結果として、数分間以上のソースデータのために相当な遅延を伴う映像ストリーミングは、おそらく、エンドユーザーに対して適切なオンデマンド経験を提供しないであろう。従って、本明細書において、これらのタイプの無線ネットワークは準実時間メディアオンデマンドサービスに対しては「十分である」とされるが、無線ストリーミングプロトコルを介した満足なユーザー経験を提供できない。]
[0033] 図3において、携帯通信システム100の例示的なバージョンが描写され、サーバ102は、映像ストリーミングサービスの待ち時間の問題を処理する方法で、通信デバイス104に、3G無線ネットワーク103を通して、準実時間メディアをオンデマンドで無線送信する。幾つかの態様によると、通信デバイス104は、任意のタイプのコンピュータ化された通信デバイスを備える。例えば、通信デバイス104は、無線および／または携帯電話などのモバイル通信デバイスを備える。あるいは、通信デバイス104は、プロキシ呼／セッション制御機能（P-CSCF）サーバ、ネットワークデバイス、サーバ、コンピュータ作業端末などの固定通信デバイスを備える。通信デバイス104は、記述または図示されたデバイスに限定されず、携帯無線端末（PDA）、両方向テキストページャ、有線または無線通信ポータルを有するポータブルコンピュータ、および、有線および／または無線通信ポータルを有する任意のタイプのコンピュータプラットフォームをさらに含みうることを理解すべきである。さらに、通信デバイス104は、遠隔センサ、遠隔サーバ、診断ツール、データリレーおよびそれらと同様のものなどの遠隔スレーブまたは別の類似デバイスであり、それはエンドユーザーを有さず、単に無線または有線ネットワークを通してデータを通信する。代替の態様において、通信デバイス104は、固定電話、パーソナルコンピュータ、セットトップボックスまたはそれらと同様のものなどの有線通信デバイスである。加えて、単一のタイプまたは複数の前述のタイプの通信デバイス104の任意の数の任意の組み合わせが携帯通信システム100において使用されうることに注意されたい。それゆえに、本装置および方法は、結果的に、有線または無線通信ポータルを含む有線または無線デバイスまたはコンピュータモジュールの任意の形態上で実行され、それは無線モデム、パーソナルコンピュータメモリカード国際連盟（PCMCIA）カード、アクセス端末、パーソナルコンピュータ、電話、または、それらの任意の組み合わせまたはサブ組み合わせを含むがそれに限定されない。]
[0034] 加えて、通信デバイス104は、メディアコンテンツ14を要求し、相互に作用し、および／または再生するといった目的のために、ユーザーインターフェース106を含む。このユーザーインターフェース106は、通信デバイス104へのユーザー入力を生成または受信することができる入力デバイス108と、通信デバイス104のユーザーによる消費についての情報を生成および／または表示することができる出力デバイス110とを含む。例えば、入力デバイス106は、キーパッドおよび／またはキーボード、マウス、タッチスクリーンディスプレイ、音声認識モジュールに関連付けられたマイクロフォンなどの少なくとも1つのデバイスを含む。特定の態様において、入力デバイス108は、コンテンツについての要求であるユーザー入力、または、さらなる情報についての要求であるユーザー入力に備える。さらに、例えば、出力デバイス110は、ディスプレイ、音声スピーカ、触覚フィードバックメカニズムなどを含む。出力デバイス110は、グラフィカルユーザーインターフェース、音、振動などの触感を生成し、それらの出力は、例えば、メディアコンテンツ14（図1）のプレゼンテーションに関連付けられる。]
[0035] さらに、通信デバイス104は、デバイス104に機能性を提供するためのアプリケーションを実行することができ、入力デバイス108および出力デバイス110とさらに相互作用するコンピュータプラットフォーム112を含む。コンピュータプラットフォーム112は、読み取り専用および／またはランダムアクセスメモリ（RAMおよびROM）、消去可能プログラム読み取り専用メモリ（EPROM）、電気的消去可能プログラム読み取り専用メモリ（EEPROM）、フラッシュメモリ、および／またはコンピュータプラットフォームに共通する任意のメモリなどの、揮発性および非揮発性メモリ部分を備えるメモリを含みうる。さらに、メモリは、電子ファイルシステムと、磁気メディア、光メディア、テープ、ソフトディスクおよび／またはハードディスクおよび取り外し可能メモリコンポーネントなどの任意の第2および／または第3記憶デバイスとを含むアクティブメモリおよび記憶メモリを含む。実例となるバージョンにおいて、メモリは、それぞれがコンピュータプラットフォームのデータバス119に接続されたRAMメモリ114、不揮発性ローカル記憶ユニット116、取り外し可能拡張メモリユニット118として描写される。]
[0036] さらに、コンピュータプラットフォーム112は、また、特定用途向けIC（ASIC）でありうるプロセッサ120または別のチップセット、プロセッサ、論理回路、または別のデータ処理デバイスを含む。通信デバイス104が携帯電話を備える場合などの幾つかの態様において、プロセッサまたは特定用途向けIC（ASIC）などの別の論理は、音声呼、データ呼およびメモリ114内のメディア関連アプリケーションなどの任意の常駐ソフトウェアコンポーネントとインターフェースするアプリケーションプログラミングインターフェース（API）層124を実行する。デバイスAPI 124は、それぞれの通信デバイス上で実行するランタイム環境である。1つのそのようなAPI 124ランタイム環境は、別に描写されるBREW（商標登録）（Binary Runtime Environment for Wireless（商標登録））API 126であり、カリフォルニア州サンディエゴのQUALCOMM株式会社によって開発された。例えば、無線計算デバイス上でアプリケーションの実行を制御するように動作する別のランタイム環境も利用される。]
[0037] 加えて、プロセッサ120は、ハードウェア、ファームウェア、ソフトウェア、およびそれらの組み合わせに組み込まれ、通信システム100上で、通信デバイス104の機能性および通信デバイス104の操作性を有効にする様々な処理サブシステム128を含む。例えば、処理サブシステム128は、通信を開始および持続し、通信デバイス104のコンポーネント内でおよび／またはコンポーネント同士でデータを交換することに加え、別のネットワークデバイスとデータを交換することを可能にする。携帯電話などにおけるある態様において、プロセッサ120は下記の処理サブシステム128の1つまたは組み合わせを含む：音、非揮発性メモリ、ファイルシステム、送信、受信、サーチャ、層1、層2、層3、主要制御、遠隔手順、ハンドセット、電力管理、診断、デジタル信号プロセッサ、ボコーダ、メッセージング、呼マネージャ、ブルートゥース（登録商標）システム、ブルートゥースLPOS、位置決定、位置エンジン、ユーザーインターフェース、スリープ、データサービス、セキュリティ、認証、USIM/SIM（万国加入者識別モジュール／加入者識別モジュール）、音声サービス、グラフィック、USB（universal serial bus）、MPEG（Moving Picture Experts Group）プロトコルマルチメディアなどのマルチメディア、GPRS（汎用パケット無線サービス：General Packet Radio Service）、ショートメッセージサービス（SMS）、ショート音声サービス（SVS（登録商標））、ウェブブラウザ、その他。開示される態様について、プロセッサ120の処理サブシステム128は、コンピュータプラットフォーム112上で実行するアプリケーションと相互作用する任意のサブシステムコンポーネントを含む。]
[0038] コンピュータプラットフォーム112は、通信デバイス104および通信ネットワーク103との間でメディアコンテンツ14およびコンテンツ要求を交換することを可能にすることに加え、通信デバイス104の様々なコンポーネント間の通信を可能にする通信モジュール130をさらに含む。通信モジュール130は、ハードウェア、ファームウェア、ソフトウェアおよび／またはそれらの組み合わせに組み込まれ、デバイス内およびデバイス間の通信において使用される全てのプロトコルをさらに含む。さらに、通信モジュール130は、本明細書に記述される装置および方法に従ってメディアコンテンツ14を要求および受信するといった情報を送信および／または受信するように動作可能である。]
[0039] 通信デバイス104の性能の幾つかは、ローカル記憶装置116からロードされた符号により容易にされ、メモリ114に保存され、オペレーティングシステム（OS）132などのプロセッサ120によって実行される。ユーザーインターフェースモジュール134は、ユーザーインターフェース130との対話形制御を容易にする。ストリーミングメディアプレーヤー136は、メディアバッファ138に含まれるストリーミングメディアコンテンツにアクセスして、出力デバイス110上でメディアコンテンツをレンダリングまたは再生する。他のアプリケーション140は、別の機能（例えば、通信呼制御、アラームクロック、テキストメッセージングなど）のために、メモリ114においてアクティブである。本開示の態様と一致するアプリケーションが他のアプリケーションを省略し、および／またはストリーミングコンテンツを受信する能力を省略しうることは、本開示の利点と共に認識されるべきである。]
[0040] 準実時間メディアオンデマンドサービスは、通信デバイス104によって利用されるサーバ102上に遠隔的に記憶された個別メディアコンテンツ142によって提供される。特に、適応メディア選択モジュール144は、トリグレット（Triglet）146として描写される個別メディアコンテンツ142のダウンロードを開始するために、拡張メモリユニット118内の十分な利用可能データ記憶装置の利用可能性に応答する。トリグレット146のメディアコンテンツは、コンパイル済のトリッグML（TrigML）コード150、アップデートチャネル152、テキスト文字列154、および／またはメモリ114でバッファされたイメージ156によって構成されるトリッグ148をアップデートするために使用される。トリッグ148は、BREWAPI 126によって処理される。BREW API 126は、アプリケーションが通信デバイス104のタイプについて詳しく書かれることなくデバイスAPI 124および他の機能を呼び出す能力を提供する。従って、適応メディア選択アプリケーション144などのアプリケーションは、特定のハードウェアの態様を抽象するBREW API 126により提供される動作環境内で、多数の異なるタイプのハードウェア構成上、まったく同じに、若しくはわずかな変更を伴って動作できる。BREW拡張162は、BREW API 126のプログラミングプラットフォームに、MP3プレーヤ、Java（登録商標）仮想マシンなどを提供するなどのさらなる性能を追加する。トリッグプレーヤ（TrigPlayer）164、トリッグ148、およびアクタ166は、QUALCOMM株式会社により開発されたuiOne（登録商標）構造のコンポーネントである。これらのコンポーネントは、通信デバイス104のユーザーインターフェース態様に関連する。BREW uiOneは、リッチでカスタマイズ可能なUI（すなわち、無線（OTA）でアップグレード可能なアクティブコンテンツ）の急速な開発を可能にし、アプリケーションを超えてダウンロードビジネスを発展させる助けとなり、一部または全部のハンドセットUIのテーマを提供し、BREW UIウィジェットを利用するBREW拡張セットである。このように、BREW uiOneは、ハンドセット、キャリアカスタマイズ、消費者個別化に関して市場化への時間を削減する。こうする為に、BREW uiOneは、BREWのためのアプリケーション開発スタックに2つの新しい層を加えて、明確な一連の抽象を提供する。]
[0041] 通信システム100の実施の開発を助けるために、BREWユーザーインターフェース（UI）は、実施を容易にするためのツールキット（図示されない）を利用する。Brew UIツールキットは、MVC（model-view-controller）設計パターンである。MVCは、今日の大多数のユーザーインターフェースフレームワークの中核であり、Java Swingを含む。MVCパターンは、グラフィカルUIアプリケーションを3つの個別部分、モデル、ビュー、コントローラに分解する。モデルは、アプリケーションドメインデータを管理し、ビューからのデータの状態についての情報に対する要求に応答し、コントローラからの要求に応答して状態を変更する責任を有する。ビューは、アプリケーションのグラフィック出力を管理する責任を有する。コントローラは、キーイベント、メニュー選択および他の入力を解釈し、命令がモデルのビューを変えるためにビューに示す要求、および、そのデータを変更するためにモデルに示す要求を送る責任を有する。]
[0042] 1つの実施形態において、コントローラはシステムのイベントポンプからイベントを受け取り、ビューまたはモデル内で起こる適切な動作を決定するために、多様性（polymorphism）または条件付論理を使用する。順に、ビューはモデルおよびコントローラから変更通知を聞き、1つの変更通知を受信すると、必要に応じて、新しいデータについてモデルにクエリする。モデル自体はアプリケーションデータの状態を追跡する。このパターンに対する一般の最適化は、ビューおよびコントローラの責任を単一プログラムエンティティに納めこむことである；Brew UIツールキットはこれを使用し、イベントハンドラに任意のビューについて特定させる。要するに、Brew UIツールキットは、各ビューにデフォルトコントローラを提供し、そのような動作は、新しいイベントハンドラを介してコントローラでオーバーライドされる。]
[0043] Brew UIツールキットは、恣意的な複雑な構造をカプセル化することができる汎用Iバリューモデル（IValueModel）と同様に、テキスト用モデル（Iテキストモデル（ITextModel））、リストおよびメニュー用モデル（それぞれIリストモデル（IListModel）、Iメニューモデル（IMenuModel））を含む特定の種類のモデルに対する幾つかのサブクラスに加えて、モデル（Iモデル）を示すベースクラスを提供する。ツールキットは、また、テキスト入力用ウィジェット、無線およびチェックボックス選択、ボタン、テキストおよびビットマップディスプレイ、メニューアイテムおよびメニューを含むユーザーインターフェースをビルド（build）する多数のユーザーインターフェース基本要素を提供する。これらの全てはIウィジェット（IWidget）インターフェースを引き継ぐ。ウィジェットはネストされ、幾つかのウィジェットは、それらが含むウィジェットに対してレイアウトおよびフォーカス制御を実行し、決定的なデスクトッププログラミングフレーバを、UIをビルドするプロセスに与える。順に、ウィジェットは、アプリケーション実施の観点からトップレベルのUIであるフォームを占有する。]
[0044] ネスティングウィジェットは複雑であるが使いやすいUIを作成し、それはBrew UIツールキットで作られる。デスクトップGUIの場合のように、ウィジェットは、別のウィジェットを含むことができる。幾つかのウィジェットは、他のウィジェットを含み、かつ、それらのレイアウトを制御するコンテナとして動作する。他のウィジェットは、所与のウィジェットを高めるために、それらの機能性をリンクすることを可能にするデコレータとして動作する。例えば、スクローリングテキストビューは2つのウィジェット：テキストを示すテキストウィジェット、およびスクローリング動作を提供し、テキストウィジェットの機能性をデコレートするスクロールバーウィジェットから成る。]
[0045] 別のウィジェットを含むウィジェットはコンテナであり、Iコンテナ（IContainer）インターフェースを実施する。Iコンテナインターフェースは、ウィジェットがコンテナとして仕事をいかに実行するかをユーザーが操作することを可能にする；Iウィジェットインターフェースは、ユーザーがウィジェット自体を操作することを可能にする。IXYコンテナ（IXYContainer）およびI制約コンテナ（IConstraintContainer）などのクラスは、オブジェクトを含む主機能を有する。ウィジェットとしてこれらのオブジェクトを使用するために、対応するウィジェットインターフェースは、ICONSTRAINTCONTAINER_QueryInterfaceを介してインスタンスから獲得される。これは、対応するコンテナオブジェクトに対するウィジェットインターフェースを要求する。]
[0046] 特定のスクリーンはウィジェットの階層から成るが、全体のアプリケーションはフォームの集合である。1つのフォームはトップレベルコンテナから成る；Brew UIツールキッドは、トップレベルのフォーム（現在スクリーン上にあるもの）およびフォームのスタックとしてその状態を追跡するために、メカニズムをアプリケーションに提供する。ユーザーがアプリケーションを使用すると、アプリケーションは、新しいフォームを作成するためにソフトキーおよび選択アイテムのようにイベントを使用し、それらをウィジェットで満たし、スタックのトップにそれらを配置する。ユーザーがフォームを出る時（例えば、クリアキーを押す時）、フォームはスタックから取り出される。ウィジェットおよびMVCパターンが価値およびその関係を概念化する能力をユーザーに提供する様に、フォームおよびフォームスタックはアプリケーション内でアプリケーションフローを概念化する方法を提供する。最高レベルで、次に、アプリケーションは1つ以上のフォームから成り、各フォームはアプリケーションのデータの状態を示す一連のモデル上で共に動作するウィジェット（ビュー）の集合を有する。多数のウィジェットは自動的にそれらの仕事を行い、ユーザーがテキストを入力またはメニューから選択値を選ぶことを可能にする。残りのウィジェットは、コントローラのフォームにおいてさらなるコードを必要とする。]
[0047] フォームはアプリケーションフローおよびグループウィジェットの概念化を容易にするが、アプリケーションはフォームを用いずにウィジェットを使用することができる。]
[0048] ウィジェットおよびフォームを両方使用する任意のアプリケーションは、ルートフォーム、各スクリーンのためのフォーム、各フォームのためのトップレベルコンテナを作成する。トップレベルフォームは2つの責任を有する。第1に、それはフォームのスタックを維持し、どのフォームがフォーカスを有するかについての意志を追跡する。第2に、タイトルおよびソフトキーラベルから成るフォームに対するコンテナユーザーインターフェースを表す。これらのウィジェットを作成して構成する責任をルートフォームが負えるようにすることで、デバイス製造業者は、全てのウィジェットベースのアプリケーション間で、類似したルック&フィールを確実にする。入力フォームは、フォームおよびそのウィジェットを作成するために遅延インスタンシエイション（lazy instantiation）を使用するInputForm_Creat方式で作成される。]
[0049] QUALCOMM株式会社に所有されているトリッグML（登録商標）コードは、XML（eXtended Markup Language）に基づいたデータ言語であり、オーサリングトリッグ（authoring Trigs）148に対するユーザーインターフェース表示言語のために使用され、数ある利点の中で特に、モバイルをターゲットとした機能性、相互作用ユーザーインターフェースイベントモデル、ピクセル位置決定の利点を含む。トリッグMLは、モバイルデバイスの制約（小さいスクリーン、メモリスペースに対する低い割り当て、抑制された計算電力）を適応するためにuiOneソフトウェア開発者キット（SDK）によって利用される、UI開発用の強力で軽量の言語である。これらの制限のパラメータ内においてでさえ、その言語は著しく強力で、かつ、張拡張性があり、開発者およびOEMは、グラフィックリッチおよびコンテンツリッチのUIを、トリッグMLを使用することによって、一般にUI開発で知られているCよりもかなり迅速に開発することができる。Cとは異なり、トリッグMLにおいては、アプリケーション論理層およびプレゼンテーション層は分離される。この相違はCにおいて使用される符号化プロセスからの戦略上、重要な出発を示す。]
[0050] トリッグMLを用いて、開発者がUIを変更したい時、プレゼンテーション層だけがカスタマイズを要求する；アプリケーション論理に手を加える必要性はない。逆に、Cで書かれたコードはプレゼンテーション層およびアプリケーション論理を混合する。このモノリシック構造（monolithic architecture）は、プレゼンテーション論理からアプリケーション論理の詳細な分析を要求し、編集プロセスを非常に複雑にする。この追加されたステップにより課された困難は、ますます供給不足の状態にあるUI開発に対して、より長いタイムフレームを必要とする。対照的に、トレッグML言語の知的設計は、開発者およびOEMのために莫大な時間を節約し、ポートフォリオ内の各デバイスに対するUI開発時間を削減し、また、多数のUI設計の基礎が再利用されることを可能にし、それにより全体的にポートフォリオが製品化されるまでの時間を削減する。]
[0051] 図3に戻り、アクタ166は、トリッグ148と基底デバイスAPI 124および／またはBREW API 126とを結合するために基底Cコードを含む基底BREW拡張162の特定のタイプである。アクタ166は、また、入力／出力のための実行可能ファイルとしてサービスする。また、アクタ166が基底デバイスAPI 124およびBREW API 126に結合するため、アクタ166はコンピュータプラットフォーム112の機能へのアクセスを有する。トリッグプレーヤ164は、個別に描写されてはいるが、BREW拡張162として実施される。トリッグプレーヤ164は、トリッグ148およびアクタ166を使用して、ユーザーインターフェース130をレンダリングする。]
[0052] 汎用ディレクトリサービス（UDSサーバ）などのサーバ102は、マルチメディアリソースファイルを含むリソース積載（resource-laden）ユーザーインターフェース（UI）ウィジェット（例えば、トリッグ148）をあらかじめパッケージおよび記憶することによって、メディアコンテンツ配信を有利に容易にすることができることを認識すべきである。ハンドヘルド通信デバイス104が、多くの場合、制限されたサイズのディスプレイスクリーン、および限られたキーボードまたは別の入力デバイスを有すると想定すると、サーバ102が、直感的におそらく、コンテンツデスクリプタとバンドルされ、あらかじめ、またはコンテンツをレンダリング／再生するためのユーザー要求に応じてダウンロードされる、あらかじめ選択された提案メディアコンテンツ選択リストであるグラフィカルユーザーインターフェース（GUI）を作成することはさらに有益である。サーバ102および／または通信デバイス104のいずれかは、転送を扱い、また、通信デバイス104上の記憶装置に対するリソースが十分か否かを決定するアクタ166を含む。あるいは、または加えて、トリッグ148は、完全なトリッグ148を再度送信するのではなく、要求された分のアップデートだけで、通信デバイス104にあらかじめダウンロードされる。トリッグ148が広告コンテンツを含みうることは、本開示の利点と共に認識されるべきである。]
[0053] 図4において、トリッグプレーヤ164は、相互に作用するUIトリッグ148およびトリグレット146のレンダリングのためにBREW拡張162としてBREWアプリケーション168上で作動する。トリッグビルダ（図示されない）は、トリッグ148のためにトリッグMLアプリケーション170をオーサリングする。トリッグMLは、BREWUIアプリケーション171として、UIレイアウト、フロー、インタラクションを記述するために使用される、XMLに基づくスクリプト言語である。BREW UIウィジェット（BUIW）172は、UIコンポーネント（ウィジェットおよびフォーム）をすばやく開発するためにフレームワークを提供する。QUALCOMM uiOne SDK（図示されない）は、開発中のワークステーション（例えばパーソナルコンピュータ（PC））（図示されない）上でのBREW UIアプリケーション171の開発、シミュレーション、実行を容易にし、トリッグビルダおよびBREWシミュレータ（図示されない）を含む。トリッグ148は、アプリケーションまたはアプリケーションセットにコンパイルされたトリッグMLコードおよび別のリソースである。トリッグ148は、トリッグプレーヤ164上で稼動する。パーセル（図示されない）は、トリッグ148のソースコンポーネント（例えば、テキスト文字列154、イメージ156など）を特定するファイルである。バイナリパーセルおよびXMLパーセル（図示されない）という2つのタイプのパーセルがある。パーセルは、下記のいずれかのためのトリッグ148およびトリグレット146のソースである：uiOne静的アプリケーションには単一のトリッグ；uiOne動的アプリケーションには複数のトリグレット；およびuiOneContentキャンペーンには複数のトリッグおよび複数のトリグレット。パーセルは、トリッグML、テキスト、イメージ、リンガー、ウォールペーパーを含む。パーセルは、簡易に転送／伝送できる単一のバイナリファイル、またはXMLメタ−ファイルで「分解された」マルチファイルのいずれかである。パーセルリソースは、トリッグMLフラグメント、イメージ（PNG）、テキスト（ユニコード）、リスト（混合、メニュー用、など）、着信音、ウォールペーパー、チャネル、テーマ（トリグレット）を含む。パーセルリソースは、トリッグおよびトリグレットのツリーへと体系づけられ、トリッグは通常はアプリケーションと同等であり、トリグレットは通常はトリッグへの小さな変更であり、それらトリッグと共に配置することができ、無線（OTA）を介して配置することができ、また、テーマになりうる。トリグレットはUI 174の任意の部分をアップデートできる。トリッグ継承（Trig inheritance）は、トリッグが別のトリッグから派生し、トリグレットがトリッグから派生し、トリグレットが別のトリグレットから派生しうることを提供する。同一のリソース経路を有する派生トリッグ／トリグレットにおけるリソースは親のリソースをオーバーライドする。]
[0054] 従来のUIにおいて、データがUIをサポートする（すなわち、データがテーマとリソース情報をUIアプリケーションコードに提供する）。しかし、BREW uiOneにおいては、全てがデータである。データがUI 174である。テーマおよびリソース情報と一緒に、データは、また、グラフィックスレイアウト、フォーカス移動および別のグラフィカル動作、ページマップ、単純なアプリケーション論理に関する情報を提供する。トリッグMLマークアップ言語は、モバイルUI 174に不適当なHTMLおよびJavaScriptのような別のマークアップ言語ではなく、データ駆動型（data-driven）UIを有利に作成する。こうして、JavaScriptのイベントモデル、HTMLのフォームリンク、SMILのアニメーションモデルといった幾つかの特徴を維持しつつ、新たなマークアップ言語トリッグMLが作成された。]
[0055] トリッグプレーヤ166は、同一ポイントから全てのトリッグ148のレンダリングを開始する。それは、/startup/フォルダ下で定義されたデフォルトと呼ばれるトリッグMLのフラグメントである。このフラグメントは、ユーザーが新しいトリッグ148を作成する時に、トリッグビルダによって自動的に作成される。任意の別のマークアップ言語と同じ様に、トリッグMLはタグを使用する。一部のタグが以下に説明される：
- このタグは現在のフラグメントに別のフラグメントを含むために使用される。]
[0056] - 層はトリッグMLの基礎で不可欠な部分である。最小UIは少なくとも1つの層を含まなければならない。層は、それらが定義された順序にスタックされた不可視なフルスクリーンコンテナである。追加の各層はメモリおよびパフォーマンス含意（performance implications）を有すため、多数の層を有することは善策ではない。]
[0057] -グループは基本コンテナエレメントである。それは空でありえ、または、その子供と呼ばれる可視エレメントを含みうる。グループエレメントは、フレーミングおよびアソシエーションという2つの目的を受け持ち、次元、境界、および背景色を有する。座標が特定されない場合、グループおよび他の可視エレメントは、それらの親の境界内に集まるであろう。]
[0058] - このタグは、物を含むという点でグループと似ているが、セルを作成するために、列および行という特別の特徴を有する。]
[0059] - このタグは、トリッグにイメージを含むために使用される。]
[0060] - このタグは、1つのイメージを使い、異なる場所でそれを反復する。トリッグプレーヤ166は、特定された全エリアをカバーするために十分な反復が行われることを提供する。]
[0061] - このタグは、静的テキストをディスプレイするために使用される。などのイベントは、イベントを投げるために使用される。]
[0062] 従来のBREWアプリケーションは、BREWAPI 162を直接使用し、またはおそらく、それらのユーザーインターフェースのためにBUIW 172を強化（leverage）し、またはおそらく、ユーザー拡張にインターフェースする。uiOne環境は、トリッグML XML語彙を使用して書かれ、ハンドセット上でQualcomm提供のトリッグプレーヤを使用して再生されるアプリケーションであるトリッグ148の概念を追加する。トリッグはアクタを強化する。アクタは、CおよびC++のために残された機能性を提供するトリッグ内のXMLと既存またはカスタム拡張との間のインターフェースであり、例えばメッセージプロトコルへのインターフェースなどである。この構造は、厳密なデータ駆動型ユーザーインターフェースの開発を可能にする。BREWトリッグベースのアプリケーション（またはトリグレット）は、アプリケーションのインターフェースのXML定義だけでなく、アプリケーションによって要求される全てのリソースを含むリソースバンドルから成る。トリッグプレーヤ166は単にブラウザというだけではなく、トリグレット146は単にMHTMLファイルと同等のBREWというだけではない。トリグレット146は、BREW拡張162によって提供された動作をカプセル化するアクタ166と相互に作用し、より複雑なプログラマティック動作を容易にする。]
[0063] アクタインターフェース166は、UIインターフェース174と同様に、イベント駆動型であり、以下のように、指定されたパラメータでイベントを投げるためにトリグレット146を容易にする：

value="+1 888 555 4444"/>

このコード片は、例えば「+1 888 555 4444」というような、指定の電話番号をダイヤルしていると思われる指定のアーギュメント番号でそのダイヤルイベントを実行するよう、ネットワークアクタに指示する。次に、アクタ166は、それ自体がトリグレット146にイベントを投げ戻すことができる。例えば、入音声呼（incoming voice call）が下記のような断片でキャッチされる：
res="popups/incomingCall"
target="popupLayer"/>
こうして、incomingCallイベントが到着する時、トリグレットのポップアップ層にincomingCallフォームをロードする。]
[0064] これらの断片は、BREWリソースフォーマット（BARファイル）上にビルドされた、トリグレット146の別の興味深いファセットを示し、仮想ファイルシステムのバーファイルコンテンツへのトリグレットインターフェースがそれである。BREW uiOneがハンドセットOEMを超えて多数のアプリケーションを有することは認識されるべきである。1つの理由は、BREW uiOneが多くの種類のアプリケーションに対するアプリケーション開発を単純化することである。今日のアプリケーションは、その幾つかは、1つのハンドセットから別のハンドセットへの平易移植を助けるために完全なXMLまたはHTMLベースのユーザーインターフェースをビルドしているが、CおよびC++でのユーザーインターフェース開発に莫大な投資を行う。他は、ポートごとに新しいスクリーンサイズおよびハンドセット容量に合うようにユーザーインターフェースを頻繁に適合させ、でなければ、現行アプリケーションのルック&フィールで妥協する。BREW uiOneはソフトウェア論理とユーザーインターフェースとを分離し、ユーザーインターフェースをデータセグメントに配置し、ユーザーインターフェースをリファインするときソフトウェア開発プロセスの間、はるかに迅速な反復を可能にする。]
[0065] トリッグML性能は、学習し易く予測可能なフレキシブルレイアウトモデルを含む。階層化は任意のオーバーラップを提供される。トリッグMLは、組み込みイベントモデルでUI動作（UI Behavior）を定義し、プラットフォームAPI 126と一体化する。トリッグMLは、リンクが全体または一部のスクリーンをロードし、任意のイベントによりトリガされうるような部分的ページローディングに備える。テンプレートサポートはマークアップ再利用のために作られる。トリッグMLはモバイルUIに適用され、メニューをスクロールするためのグリッドおよびリスト、テキストおよびイメージをスクロールするためのチッカー、アニメーション効果を含む。トリッグMLはUIウィジェット172上にビルドされる。]
[0066] エレメントは、1つのアプレットおよび複数のトリッグプレーヤウィジェットで、トリッグプレーヤ166のインスタンスを再帰的にネストし、任意の別の可視エレメント同様、親の階層に住みつく。各トリッグプレーヤは、.TMFファイルおよび.BARファイルのリスト、> VFS、/var、アップデートチャネル、トリグレット、永続的格納を有する自己の私的環境を有する。こうして、ロバスト性およびモジュール方式関する利益が、ネストされたトリッグプレーヤが親への最小限度の制御されたアクセスを有することにおいて提供される。トリッグプレーヤは、ユーザーインターフェース174内で、アップデート可能で、たぶん第三者コンテンツの「サンドボックス」アイランドについての解法を提供する。ネストされたトリッグのために到着するトリグレットは、そのトリッグのみをアップデートする。ネストされたトリッグのトリッグメタフィアル（.TMF）ファイルへのBREWファイルシステム経路は、ネストされたトリッグプレーヤにロードするためにバーファイルを特定し、その名称は、BREWにおいて、ネストされたトリッグに唯一のディレクトリを提供するために使用される。]
[0067] 図5において、制限スループット無線ネットワークを通してメディアコンテンツを配信するために、方法200が描写される。ブロック202において、全ての、一部の、または個々の通信デバイスについて、メディアコンテンツに対する嗜好がアクセスまたは予測される。予測の例は、特定のウェブページポータルについて最も人気のある映像ダウンロードのリストにアクセスすることである。より個別的に適合されたアプローチは、明確な嗜好の設定、または、新しいメディア提供についての類別と通信デバイスの個々のユーザーによってアクセスされ再生されるメディアコンテンツの類別とを比較することである。ブロック204において、ストリーミングメディアコンテンツを備えうるメディアコンテンツは、配信のための利用可能性のためにアクセスされる。ブロック206において、個別メディアコンテンツ（例えばトリッグ、トリグレット）は、記憶容量を有する通信デバイスへのメディアコンテンツ配信の効率を高めるためにストリーミングメディアコンテンツからビルドされる。ブロック208において、配信は、通信デバイスの集団についての構成データにアクセスすること、または通信デバイスへの現行または予測されたネットワークスループットを決定すること、または他の制約により、さらに高められる。次に、ブロック210において、個別メディアコンテンツのバックグラウンドスケジューリングが、そのようなコンテンツを受信することができるそれらのデバイスによって制約され、およびネットワークが配信を処理するために余分な容量を有する時に送信されるように作られる。ブロック212において、メディアコンテンツの送信を保証するイベントトリガが起こったか否かについての決定が行われる。そのようなスケジューリングは、余分な容量を有する無線デバイスの一部内で現在検知されている通信デバイス、またはそれに関してダウンロードを起こすことが可能な高帯域幅の通信呼を現在行っている通信デバイスを優先させるといったように、動的にアップデートされる。優先化は準実時間メディアオンデマンドサービスの使用履歴を有する通信デバイスに行われる。あるいは、または加えて、スケジューリングは、送信を達成するために拡張期間を通して低帯域幅、低コストチャネルを利用する。ブロック212において、トリガしているイベントがない場合、プロセスは、そのような配信のための準備を継続するためにブロック202に戻る。]
[0068] 例示的なバージョンにおいて、システムのネットワークサイドは、個別メディアコンテンツを記憶することができない場合、メディアコンテンツを通信デバイスにストリームする能力を保持する。さらに、例示的バージョンは、通信デバイス上で個別メディアコンテンツの記憶装置を遠隔的に管理することで、個別メディアコンテンツのプッシュを高めることができる。例えば、1つ以上の短縮トリグレットをダウンロードすることは、ネストトリグレットまたはホストトリッグ上でリソースを上書きすることができ、さもなければ、さらなるリソースを利用可能にするために、期限切れコンテンツの削除を命令する。あるいは、または加えて、所望のメディアコンテンツの予測は、通信デバイス特定のモデルで知られる記憶装置限度内でサポートすることができるように、または、それの現行状態として通信デバイスによって報告された通りに、より短いリスティングに縮小される。従って、ブロック214において、目標通信デバイス上において記憶装置が利用可能か否かについての決定が行われる。利用可能でない場合、ブロック216において、リソースを使えるようにする／ダウンロードを制限する努力が成功するか否かについてのさらなる決定が行われる。成功しない場合、制限スループットネットワークに固有の必須の無線待ち時間を伴うにも拘わらず、メディアコンテンツをストリームすること（ブロック218）が実行される。ブロック214または216のいずれかにおいて記憶装置が利用可能であった場合、ブロック220において、個別メディアコンテンツ（例えばトリグレット）が、遠隔通信デバイスへの配信のために送信される。]
[0069] 図6において、制限スループット無線ネットワークを通してメディアコンテンツを受信するために、方法300が描写される。ブロック302において、メディアサービスがハンドヘルドデバイス上で開始される。メディア経験を高めるために、利用可能なメディアコンテンツは、例えば、エンドユーザーの嗜好に関して、またはエンドユーザーの一般的な観衆による要求の頻度によって決定されるように、あらかじめダウンロードされたリスティングまたは別のグラフィカルユーザーインターフェース（GUI）プレゼンテーションに要約される。ハンドヘルドデバイスの記憶装置の利用可能性がブロック304において決定される。十分でない場合、メディアコンテンツはストリーミング配信のために選択され、ブロック306において必要に応じてバッファされる。受信されたストリーミングメディアコンテンツはブロック308においてレンダリングまたは再生される。ブロック304で十分なメモリが決定された場合、個別メディアコンテンツ（例えば、UIウィジェット、トリッグ）がブロック310において要求され、ブロック312においてハンドヘルドデバイスに記憶される。ユーザー経験さらに高めるために、メディアコンテンツ配信に対するこの要求は、嗜好がアクセスされるように自動化されうる。コンテンツは、余分のスループットを使用して送信される（例えば、オフピーク時間の間、余分な帯域幅が利用可能である通信呼の間、より有能なネットワーク通信が利用可能な時など）。ブロック314における監視は、記憶装置がもはや利用可能でないかを決定する（例えば、取り外し可能メモリ記憶装置が取り外される；別のアプリケーションがすでに利用可能メモリ記憶装置を使用している、など）。ブロック314においてメモリが利用可能でない場合、ストリーミングメディアコンテンツへの復帰は、ブロック316において記憶装置が再度利用可能になったか否かについて行われるチェックを伴って、ブロック306および308に行くことで行われる。ブロック314またはブロック316において、記憶装置が利用可能であるとわかると、ブロック318において必要に応じてさらなる個別メディアが再ロードされ、記憶されたメディアコンテンツは、ブロック314において利用可能な記憶装置を監視するために行われる反復を伴って、ブロック320において再生される。]
[0070] 本明細書に開示された態様と関連して記述される様々な実例となる論理、論理ブロック、モジュール、回路は、汎用のプロセッサ、デジタル信号プロセッサ（DSP）、特定用途向けIC（ASIC）、書替え可能ゲートアレイ（FPGA）又は他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、若しくは本明細書に記述された機能を実行するよう設計されたこれらの任意の組み合わせと一緒に実行または実施される。汎用のプロセッサはマイクロプロセッサであるが、代替で、プロセッサは、任意の従来型プロセッサ、コントローラ、マイクロコントローラ、ステートマシン（state machine）でありうる。プロセッサは、また、例えば、DSPとマクロプロセッサ、複数のマイクロプロセッサ、DSPコアに結合した1つ以上のマイクロプロセッサ、その他の上記構成の組み合わせといった計算デバイスの組み合わせとしても実施される。加えて、少なくとも1つのプロセッサは、1つ以上の上記ステップおよび／または動作を実行することが可能な1つ以上のモジュールを備える。]
[0071] さらに、本明細書に開示された態様に関して示される方法またはアルゴリズムのステップおよび／または動作は、直接的にハードウェアに、プロセッサによって実行されるソフトウェアモジュールに、またはそれら二つの組み合わせに組み込まれうる。ソフトウェアモジュールは、ランダムアクセスメモリ（RAM）、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、取外し可能ディスク、CD-ROM、または本技術分野において周知の記憶メディアの任意の他のフォームに存在しうる。例示的な記憶メディアは、プロセッサが記憶メディアから情報を読み取り、記憶メディアに情報を書き込むことができるプロセッサに結合される。代替において、記憶メディアはプロセッサに一体化される。さらに、いくつかの態様において、プロセッサと記憶メディアはASICに存在しうる。加えて、ASICはユーザー端末に存在しうる。代替において、プロセッサと記憶メディアは、個別コンポーネントとして、ユーザー端末に存在しうる。加えて、幾つかの態様において、方法またはアルゴリズムのステップおよび／または動作は、ステップおよび／または動作をコンピュータに実行させることが可能なコンピュータプログラム製品に組み込まれうる機械読み取り可能メディアおよび／またはコンピュータ読み取り可能メディア上の少なくとも1つの命令、または、符号および／または命令の任意の組み合わせまたはセットとして存在しうる。]
[0072] 前述の開示は実例となる態様および／または実施を議論してはいるが、様々な変更および修正は、添付された請求項により定義されるように、記述された態様および／または実施の範囲を逸脱することなく本明細書において行われうることに注意されたい。]
[0073] さらに、記述された態様および／または実施のエレメントは、単数形で記述またはクレームされ、単数形への限定が明示的に述べられない場合、複数形が予想される。さらに、任意の態様および／または実施の全部または一部は、別に記述がない場合、任意の別の態様および／または実施の全部または一部で利用されうる。]

权利要求:

請求項1
スループットが制限されたネットワークを通してメディアコンテンツを受信する方法であって：利用可能なローカルデータ記憶装置容量を検出することと；メディアコンテンツ選択に関するユーザー嗜好を決定することと；前記利用可能なローカルデータ記憶装置容量が閾値以下であることに応答して、ポータブル通信デバイス上で前記メディアコンテンツ選択のストリーミングバージョンをアクセスして再生することと；前記利用可能なローカルデータ記憶装置容量が閾値を超えていることに応答して、前記利用可能なローカルデータ記憶装置に前記メディアコンテンツ選択の個別にフォーマットされたバージョンを記憶することと；を備える方法。
請求項2
ユーザー要求に応答して、前記ポータブル通信デバイス上で、前記メディアコンテンツ選択の前記記憶された個別にフォーマットされたバージョンを再生することをさらに備える、請求項1の方法。
請求項3
前記メディアコンテンツ選択の前記個別にフォーマットされたバージョンを記憶することは、アップデートチャネル、実行可能ユーザーインターフェースコード、およびメディアコンテンツを備えるデータ構造コンテナを受信することをさらに備える、請求項1の方法。
請求項4
前記メディアコンテンツ選択の前記個別にフォーマットされたバージョンを記憶することは、トリッグユーザーインターフェースアプリケーションを受信することを備える、請求項1の方法。
請求項5
記憶されたトリッグをアップデートするトリグレットを受信することをさらに備える、請求項4の方法。
請求項6
前記利用可能なローカルデータ記憶装置容量を検出することは、取り外し可能な拡張メモリデバイスの存在を検出することをさらに備える、請求項1の方法。
請求項7
前記メディアコンテンツ選択の前記個別にフォーマットされたバージョンを記憶することは、前記メディアコンテンツ選択の持続時間の4分の1を超える無線待ち時間によって特徴づけられたスループットを有する無線ネットワークを通して前記個別にフォーマットされたバージョンを受信することをさらに備える、請求項1の方法。
請求項8
スループットが制限されたネットワークを通してメディアコンテンツを配信する方法であって：メディアコンテンツの選択を決定することと；アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造を備えた前記選択の個別メディアコンテンツバージョンを獲得することと；前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量を決定することに応答して、スループットが制限されたネットワークを通して前記個別メディアコンテンツバージョンを送信することと；を備える方法。
請求項9
前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量不足を決定することに応答して、前記選択のストリーミングメディアコンテンツバージョンを送信することをさらに備える、請求項8の方法。
請求項10
前記通信デバイス上でユーザーインターフェースをアップデートするために、トリグレットを獲得することをさらに備える、請求項8の方法。
請求項11
前記通信デバイスに対する制約に従って、前記個別メディアコンテンツバージョンの配信をスケジュールすることをさらに備える、請求項8の方法。
請求項12
ネットワーク利用可能性に基づいて前記制約を決定することをさらに備える、請求項11の方法。
請求項13
前記通信デバイスの使用パターンに基づいて前記制約を決定することをさらに備える、請求項11の方法。
請求項14
前記個別メディアコンテンツバージョンを送信する前に、前記通信デバイス上で記憶されたコンテンツの削除を命令することをさらに備える、請求項11の方法。
請求項15
前記メディアコンテンツの選択を決定することは、前記メディアコンテンツ選択に関するユーザー嗜好を決定することをさらに備える、請求項8の方法。
請求項16
広告コンテンツを前記個別にフォーマットされたメディアコンテンツ選択に組み込むことをさらに備える、請求項8の方法。
請求項17
スループットが制限されたネットワークを通してメディアコンテンツを受信するように構成された少なくとも1つのプロセッサであって：利用可能なローカルデータ記憶装置容量を検出する第1のモジュールと；メディアコンテンツ選択に関するユーザー嗜好を決定する第2のモジュールと；前記利用可能なローカルデータ記憶装置容量が閾値以下であることに応答して、ポータブル通信デバイス上で前記メディアコンテンツ選択のストリーミングバージョンをアクセスして再生する第3のモジュールと；前記利用可能なローカルデータ記憶装置容量が閾値を超えていることに応答して、前記利用可能なローカルデータ記憶装置に前記メディアコンテンツ選択の個別にフォーマットされたバージョンを記憶する第4のモジュールと；を備えるプロセッサ。
請求項18
コンピュータ読み取り可能メディアを備えるコンピュータプログラム製品であって、前記コンピュータ読み取り可能メディアは：利用可能なローカルデータ記憶装置容量をコンピュータに検出させるための少なくとも1つの命令と；メディアコンテンツ選択に関するユーザー嗜好を前記コンピュータに決定させるための少なくとも1つの命令と；前記利用可能なローカルデータ記憶装置容量が閾値以下であることに応答して、ポータブル通信デバイス上で前記メディアコンテンツ選択のストリーミングバージョンを前記コンピュータにアクセスおよび再生させるための少なくとも1つの命令と；前記利用可能なローカルデータ記憶装置容量が閾値を超えていることに応答して、前記利用可能なローカルデータ記憶装置に前記メディアコンテンツ選択の個別にフォーマットされたバージョンを前記コンピュータに記憶させるための少なくとも1つの命令と；を備える、コンピュータプログラム製品。
請求項19
利用可能なローカルデータ記憶装置容量を検出する手段と；メディアコンテンツ選択に関するユーザー嗜好を決定する手段と；前記利用可能なローカルデータ記憶装置容量が閾値以下であることに応答して、ポータブル通信デバイス上で前記メディアコンテンツ選択のストリーミングバージョンにアクセスして再生する手段と；前記利用可能なローカルデータ記憶装置容量が閾値を超えていることに応答して、前記利用可能なローカルデータ記憶装置に前記メディアコンテンツ選択の個別にフォーマットされたバージョンを記憶する手段と；を備える装置。
請求項20
スループットが制限されたネットワークを通してメディアコンテンツを受信する装置であって：ローカルデータ記憶装置と；メディアコンテンツ選択に関するユーザー嗜好を受信するためのインターフェースと；メディアプレーヤと；前記メディアプレーヤ上で前記メディアコンテンツ選択のストリーミングバージョンにアクセスして再生するために前記ローカルデータ記憶装置の利用可能な記憶容量が閾値以下であることに反応し、前記メディアコンテンツ選択の個別にフォーマットされたバージョンを記憶するために前記ローカルデータ記憶装置の前記利用可能な記憶容量が前記閾値を超えることに反応するコントローラと；を備える装置。
請求項21
前記ローカルデータ記憶装置は、取り外し可能なメモリデバイスを備える、請求項20の装置。
請求項22
前記メディアプレーヤはトリッグプレーヤを備え、前記個別メディアコンテンツはトリグレットを備える、請求項20の装置。
請求項23
前記メディアコンテンツ選択の前記個別にフォーマットされたバージョンは、アップデートチャネル、実行可能ユーザーインターフェースコード、およびメディアコンテンツを備えるデータ構造コンテナをさらに備える、請求項20の装置。
請求項24
前記メディアコンテンツ選択の持続時間の4分の1を超える無線待ち時間によって特徴付けられたスループットを有する無線ネットワークを通して前記個別にフォーマットされたバージョンを受信可能な通信インターフェースをさらに備える、請求項20の装置。
請求項25
スループットが制限されたネットワークを通してメディアコンテンツを配信するように構成された少なくとも1つのプロセッサであって：メディアコンテンツの選択を決定する第1のモジュールと；アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造を備えた前記選択の個別メディアコンテンツバージョンを獲得する第2のモジュールと；前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量を決定することに応答して、スループットが制限されたネットワークを通して前記個別メディアコンテンツバージョンを送信する第3のモジュールと；を備えるプロセッサ。
請求項26
コンピュータ読み取り可能メディアを備えるコンピュータプログラム製品であって、前記コンピュータ読み取り可能メディアは：メディアコンテンツの選択をコンピュータに決定させるための少なくとも1つの命令と；アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造を備えた前記選択の個別メディアコンテンツバージョンをコンピュータに獲得させるための少なくとも1つの命令と；前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量を決定することに応答して、スループットが制限されたネットワークを通して前記個別メディアコンテンツバージョンをコンピュータに送信させるための少なくとも1つの命令と；を備える、コンピュータプログラム製品。
請求項27
メディアコンテンツの選択を決定する手段と；アップデートチャネルおよびユーザーインターフェースを含むデータ構造を備えた前記選択の個別メディアコンテンツバージョンを獲得する手段と；前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量を決定することに応答して、スループットが制限されたネットワークを通して前記個別メディアコンテンツバージョンを送信する手段と；を備える装置。
請求項28
スループットが制限されたネットワークを通してメディアコンテンツを配信するための装置であって：メディアコンテンツを選択するためのプロセッサと；アップデートチャネルおよびユーザーインターフェースコードを含むデータ構造を備えた前記選択されたメディアコンテンツの個別メディアコンテンツバージョンを収容するためのネットワーク記憶装置と；前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量の決定に応答して、スループットが制限されたネットワークを通して前記個別メディアコンテンツバージョンを配信するための送信機と；を備える装置。
請求項29
前記スケジューリングディスパッチャは、前記個別メディアコンテンツバージョンを記憶するために、通信デバイスの容量不足を決定することに応答して、前記選択のストリーミングメディアコンテンツバージョンを送信することがさらに可能である、請求項28の装置。
請求項30
前記メディアディストリビュータは、前記通信デバイス上でユーザーインターフェースをアップデートするためにトリグレットを獲得することがさらに可能である、請求項28の装置。
請求項31
前記スケジューリングディスパッチャは、前記通信デバイスの制約に従って前記個別メディアコンテンツバージョンの配信をスケジュールすることがさらに可能である、請求項28の装置。
請求項32
前記スケジューリングディスパッチャは、ネットワークの利用可能性に基づいて前記制約を決定することがさらに可能である、請求項31の装置。
請求項33
前記スケジューリングディスパッチャは、前記通信デバイスの使用パターンに基づいて前記制約を決定することがさらに可能である、請求項31の装置。
請求項34
前記スケジューリングディスパッチャは、前記個別メディアコンテンツバージョンを送信する前に、前記通信デバイス上に記憶されたコンテンツの削除命令を決定することがさらに可能である、請求項31の装置。
請求項35
前記メディアディストリビュータは、前記メディアコンテンツ選択に関するユーザー嗜好に基づいて前記メディアコンテンツの選択を決定することがさらに可能である、請求項28の装置。
請求項36
前記メディアディストリビュータは、広告コンテンツを前記個別にフォーマットされたメディアコンテンツ選択に組み込むことがさらに可能である、請求項28の装置。